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Cross-Domain  Payload  Migration:  Space  payload 
development  typically  occurs  over  relatively  long 
timelines,  given  the  risks,  costs,  and  other  factors.  This 
fact  motivates  developers  to  investigate  other  payloads 
and  platforms,  in  aviation  and  terrestrial  systems,  for 
example,  as  a  means  of  gaining  experience  with  state- 
of-the-art  technology  and  exercising  the  methods  and 
processes  used  in  engineering  high-reliability  space 
systems.  Increasingly,  systems  developed  for  aviation 
and  terrestrial  platforms  serve  as  risk-reducing  proto¬ 
types  for  eventual  space  missions.  Remote  operation 
of  payloads  deployed  in  unmanned  aviation  platforms 
and  unattended  ground  systems  provides  a  realistic 
operating  environment  for  simulating  control  of  a 
space  payload. 

The  tradespace  of  hardware  and  software  required 
to  successfully  support  many  Navy,  Marine  Corps,  and 
DoD  missions  exhibits  commonality  that  could  be  used 
across  multiple  payload  and  platform  domains.  Com¬ 
parison  of  characteristics  and  requirements  between 
payload  domains  shows  many  solutions  to  be  more 
alike  than  different.  The  Naval  Research  Laboratory 
has  demonstrated  on  several  payload  developments 
the  feasibility  of  designing  advanced,  state-of-the- 
art  systems  for  use  across  multiple  domains  and  the 
reduced  development  costs  which  result,  especially  for 
shared  software  systems. 

Moving  Beyond  Single-Purpose  Payloads:  In 

examining  the  organizations,  companies,  laboratories, 
and  other  facilities  often  supporting  DoD  development 
activities,  it  is  common  to  note  a  stovepiped  mentality. 
The  space  development  organizations  tend  to  be  sepa¬ 
rated  from  the  aviation  and  ground  solutions  people. 
These  structures  often  mirror  that  of  the  sponsoring 
organization,  resulting  from  security  classification, 
from  separation  of  funding  sources,  and  other  factors. 
For  a  more  than  a  decade,  DoD  has  specifically  focused 
on  breaking  down  stovepipes  so  that  within  organiza¬ 
tions  there  is  more  visibility  across  the  portfolio  of 
projects  and  development  efforts.  Current  economic 
realities  and  the  need  to  share  information  help  bring 
down  stovepiping. 

The  Naval  Research  Laboratory  provides  a  unique 
environment  to  support  those  efforts  with  a  broad 
multidisciplinary  approach  across  our  divisions.  Since 
many  of  our  sponsoring  organizations  are  also  in  a 
position  to  see  across  the  multiplatform  solution  space, 
they  are  able  to  recommend  development  projects  and 
solutions  that  can  end  up  being  more  efficient.  Encour¬ 


aging  NRL  scientists  and  engineers  and  our  DoD 
sponsors  to  think  ahead  during  the  specification  and 
design  phase  about  applying  their  work  across  multiple 
domains  is  advantageous.  In  the  Space  Systems  Devel¬ 
opment  Department,  it  has  been  a  philosophy  to  “solve 
the  problem  once”  to  the  largest  extent  possible.  We 
continue  to  strive  to  meet  that  ideal. 

Case  Study —  Copperfield-2:  The  Copperfield-2 
(CuF2)  payload  system  for  use  in  ground,  aviation, 
and  space  platforms  serves  to  demonstrate  a  core  R&D 
product  NRL  has  successfully  demonstrated  across 
multiple  platforms.  The  CuF2  system  was  developed 
as  an  experimental  platform  for  a  flexible,  recon- 
figurable  payload.  When  the  first  concepts  were  put 
together,  the  design  focused  on  a  single  type  of  aviation 
platform.  However,  as  the  architecture  evolved,  the 
engineers  made  design  decisions  and  trades  that  sup¬ 
ported  “future  proofing”  the  system  and  provided  for 
expanded  utility.  With  the  broader  capability  designed 
into  the  hardware  and  software,  CuF2  became  a  core 
product  and  acted  as  a  springboard  to  a  number 
of  other  unforeseen  projects,  each  program  adding 
further  capability  valuable  to  follow-on  work.  This 
produced  a  library  of  hardware  and  software  applica¬ 
tions,  and  a  menu  from  which  modular  systems  could 
be  constructed.  The  history  of  the  development  shows 
the  migration  across  platform  domains. 

Not  all  of  the  platforms  and  domains  listed  in 
Table  2  came  to  fruition  in  an  actual  demonstration, 
but  in  no  case  did  a  limitation  of  the  payload  design 
prevent  further  application.  While  CuF2  started  life 
with  a  specific  radio  requirement  in  mind,  its  success 
has  been  defined  by  its  capability  to  adapt  to  new 
signals  that  were  of  no  interest  when  the  payload  was 
first  designed. 

Furthering  Cross-Platform  Applicability:  As 

development  continues  with  the  next  generation  of 
payloads  under  the  Software  Reconfigurable  Payload 
(SRP)  portfolio  of  products,  providing  built-in  flexibil¬ 
ity  becomes  a  design  rule.  The  “best  practices”  used  in 
the  design,  implementation,  and  construction  of  space 
payloads,  with  their  higher  complexity  and  expense,  are 
also  in  line  with  the  best  practices  one  uses  in  the  devel¬ 
opment  and  design  of  aviation  payloads,  and  really 
help  to  increase  the  reliability  of  any  system.  Engineer¬ 
ing  trades  must  be  undertaken  to  optimize  capability 
versus  cost,  however:  it  is  often  difficult  to  articulate  in 
a  requirements  document  “latent  capability.” 

The  biggest  challenge  one  finds  in  developing 
cross-domain  solutions  is  selecting  high-performance 
components  for  terrestrial  and  aviation  applications 
that  will  also  operate  successfully  in  the  higher  radia¬ 
tion  levels  encountered  in  the  space  environment. 
Thermal,  vibration  and  shock,  and  vacuum  effects  can 


172 


INFORMATION  TECHNOLOGY  AND  COMMUNICATIONS 


all  be  readily  accommodated  through  careful  manage¬ 
ment  of  the  environmental  control  systems.  Indeed, 
shock  and  vibration  are  often  a  more  challenging 
problem  in  aviation  and  terrestrial  systems  —  rocket 
rides  are  short  in  duration,  and  extremes  of  tempera¬ 
ture  are  very  unusual  events.  Sitting  on  the  tarmac 
in  the  desert  for  8  hours  of  sunlight  often  presents  a 
more  challenging  thermal  design  problem  than  the  one 
encountered  in  the  design  of  space  payloads.  Figure  5 
shows  the  variety  of  payload  operating  domains  and 
corresponding  packaging  techniques. 

Different  types  of  electronic  components  used 
in  payloads  respond  differently  to  radiation  environ¬ 
ments  depending  on  their  underlying  technology. 

RF  components  are  inherently  more  tolerant  due  to 
the  semiconductor  processes  used  to  construct  them. 
High-speed  processors  and  field-programmable  gate 
arrays  (FPGAs)  tend  to  be  “softer”  and  can  be  affected 
by  total-dose  radiation,  producing  a  slow  degrada¬ 
tion  of  performance,  or  by  highly  energetic  bursts  of 
radiation,  causing  “single-event  upsets”  that  change 
memory  states.  Permanent  failure  may  even  result 
when  a  highly  charged  particle  hits  a  particularly  sus¬ 
ceptible  semiconductor  device,  causing  “single-event 
burnout.”  In  the  realm  of  digital  processing,  radiation 
tolerant  parts  are  available  —  but  parts  today  tend  to 
be  at  least  a  decade  behind  parts  that  are  commercially 
available  for  use  in  terrestrial  and  aviation  applica¬ 
tions.  NRL  experience  has  shown  that  a  compromise 
design  with  radiation-hardened  circuitry,  but  much  of 
the  same  software  components,  provides  for  the  best 
portability  for  cross-domain  applications.  On-orbit 
experience  has  also  shown  that  within  the  tradespace  of 
cost,  complexity,  and  reliability,  selected  commercial 
non-radiation-hardened  components  can  be  success¬ 
fully  flown  and  provide  useful  mission  life.  Sponsors 
must,  however,  understand  the  cost-benefit  trade  and 
the  risks  involved. 


Conclusions:  Payload  design  engineers  have  within 
their  toolbox  the  ability  to  create  systems  that  are 
relevant  beyond  a  single  operational  domain.  Keeping 
the  most  challenging  attributes  of  each  domain  in 
mind  during  the  design  process,  intelligent  engineer¬ 
ing  trades  can  be  made  that  maximize  capability.  NRL 
experience  in  providing  terrestrial,  aviation,  and  space 
platforms  validates  the  flexibility,  extensibility,  and  cost 
and  schedule  savings  that  may  be  realized.  The  goal  of 
“solving  the  problem  once”  is  obtainable,  and  in  the 
longer  term  provides  more  capability  to  more  payload 
systems  with  reduced  overall  cost. 

[Sponsored  by  ONR] 


TABLE  2  —  Payload  Migration  History 


Platform 

Domain 

Year 

Predator  class  UAS 

Aviation 

2001 

Firescout  class  UAS 

Aviation 

2003 

TacSat-1 

Spacecraft 

2004 

Tier-II  UAS 

Aviation 

2005-6 

TIE/TacSat-2 

Spacecraft 

2006 

Subsurface 

Subsurface 

2006-7 

GlobalHawk 

Aviation 

2008 

MSS 

Terrestrial 

2008 

TacSat-1  A 

Spacecraft 

2008/9 
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FIGURE  5 

Various  form  factors  and  hardware  examples  for  those  domains. 
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